home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000318_connolly@pixel.convex.com _Thu Nov 12 22:07:39 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  3KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA08527; Thu, 12 Nov 92 22:07:39 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA08315; Thu, 12 Nov 92 22:20:26 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA20012; Thu, 12 Nov 92 15:19:27 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA26490; Thu, 12 Nov 92 15:19:31 -0600
  10. Message-Id: <9211122119.AA26490@pixel.convex.com>
  11. To: Jim Davis <davis@dri.cornell.edu>
  12. Cc: www-talk@nxoc01.cern.ch
  13. Subject: Re: indexes as links rather than documents 
  14. In-Reply-To: Your message of "Thu, 12 Nov 92 15:40:14 EST."
  15.              <199211122040.AA13231@willow.tc.cornell.edu> 
  16. Date: Thu, 12 Nov 92 15:19:30 CST
  17. From: Dan Connolly <connolly@pixel.convex.com>
  18.  
  19.  
  20. >As I understand it, the distinction between an indexed document
  21. >and an ordinary one is that an indexed document is really
  22. >an abstract document.   Once you provide the index terms,
  23. >then it is concrete document.  So a Dictionary is abstract
  24. >until I send it a keyword, then I get back a real document,
  25. >the definition for the word.
  26.  
  27. The most useful definition of a document I've seen is "a unit
  28. of retreival." Since you can't retrieve the index -- only
  29. summaries of the index, query results from the index, etc. --
  30. the index isn't a document by that definition.
  31.  
  32. >In the case of the dictionary, of course, one could argue
  33. >that the Dictionary as a whole is also a concrete document,
  34. >since it would be possible to just read it cover to cover.
  35.  
  36. If we had a protocol to do this, yes...
  37.  
  38. >Maybe this can be addressed in HTML2, by some process of negotiation
  39. >between server (abstract document) and user/client.  e.g the document
  40. >sends something back saying "I will give you a page of text but
  41. >first send me at least one line of ascii".  If this is the
  42. >right approach, then we need a means of describing data types and prompts.
  43. >The negotiation might take several exchanges, or it might be done
  44. >by having the server return a small program, something like a decision
  45. >tree, to prompt the user for all meaningful values required for
  46. >the input.
  47.  
  48. Clarification: this shouldn't impact HTML significantly. It should
  49. impact HTTP, the protocol. Whether the forms description/query
  50. language should become part of HTML isn't clear. I'd say: no, it
  51. should be a separate beast.
  52.  
  53. Tim mentioned the same scenario, with servers sending out forms,
  54. clients with "forms editors" and complex queries.
  55.  
  56. The closest thing I've seen to an implementation of this is the
  57. Dynatext browser. There's some sort of query dialog description
  58. language: I think it's an SGML language. So you describe the dialog
  59. with an SGML document. The browser displays toggle buttons, text
  60. fields etc. The user fills in the fields, clicks OK, and the
  61. query results come up in the table of contents window.
  62.  
  63. Dan
  64.